Rich media data extends traditional computer data formats into more natural data formats for the interaction of humans and computers by incorporating images, motion pictures, voice, audio, and video. The distribution of rich media data creates some new issues, namely the need for transferring a huge amount of data. In order to handle this, the streaming of video and generally of media has been established in recent years.
Streaming video is a sequence of “moving images” that are sent in compressed form over the Internet and displayed by a viewer as they arrive. Streaming audio is a sequence of compressed sound segments for the same use. Streaming media comprises streaming video with streaming audio. With streaming video or streaming media, a Web user does not have to wait to download a large file before seeing the video or hearing the sound. Instead, the media is sent in a continuous stream and is played as it arrives. The user needs a player, which is a special program that uncompresses and sends video data to the display and audio data to speakers. A player can be either an integral part of a browser or downloaded from the software maker's Web site.
Major streaming video and streaming media technologies include RealSystem™ G2 from RealNetworks, Microsoft Windows® Media Technologies, IBM Video charger/Video charger player and Apple QuickTime. The standard MPEG (Moving Picture Experts Group) compression algorithm may be used for video. Other approaches use proprietary algorithms. Present technology offers streaming audio at up to 96 Kbps and streaming video at up to 8 Mbps. However, for most Web users, the streaming video will be limited to the data rates of the connection; e.g., up to 128 Kbps with an ISDN connection.
Streaming video is usually sent from pre-recorded video files, but can be distributed as part of a live broadcast “feed.” In a live broadcast, the video signal is converted into a compressed digital signal and transmitted from a special Web server that is able to do multicast; i.e., sending the same file to multiple users at the same time.
In today's electronic business environment, standard HTML (Hypertext Markup Language) browsers, i.e., programs allowing a person to read hypertext, are the most popular way to access information and applications in distributed information systems, such as the Internet. These browsers communicate to servers utilizing standard protocols like http (Hypertext Transfer Protocol) and ftp (File Transfer Protocol), whereby a server is a computer that provides some service for other computers connected to it via a network. The most common example is a file server that has a local disk and services requests from remote clients to read and write files on that disk.
The browser's behavior is limited by the capabilities provided by a respective communication protocol; e.g., the ftp protocol is optimized to tasks related to file upload and download, whereas the http protocol is designed to handle more complex requirements, such as files that can contain references to other files whose selection will elicit additional transfer requests.
Within an http communication between the browser and a web server, MIME-Type (Multipurpose Internet Mail Extensions), which is being part of the http reply, allows the browser to determinate the type of data it is currently receiving from the server.
Once the browser determines the type of data it is receiving, it is then capable of doing more complicated tasks such as starting external applications and passing the received information to those applications. Nevertheless, the browser's capabilities are limited to the features provided by the supported protocols, such as the http protocol and the ftp protocol. Some protocols used for streaming, like RTSP (Real Time Streaming Protocol), have to fulfill other requirements, which are not available in a default web browser.
Two kinds of streaming have been established over time: HTTP Streaming transports media data over HTTP but is very limited when it comes to operations like forwarding or rewinding a stream. Therefore, it is mostly used with live feeds and low quality feeds. In opposition to this, “regular” streaming utilizes a special streaming protocol like RTSP which solves such protocol related restrictions. However, the latter requires the introduction of so called streaming metadata in order to enable browsers to start a web application that initiates the streaming. In general such metadata represents a link to rich media data content being hosted on a streaming server. This metadata is passed to a player, which is able to connect to the streaming server and request the rich media data stream for rendering.
The combination of player, streaming server and the format of the metadata used by the player to connect to a stream are usually kept proprietary by their manufacturers. In order to enable streaming of rich media files through different streaming servers and therefore to different players, proprietary metadata for each player/server pair needs to be provided. In an environment in which millions of different rich media files are held for streaming, the effort required for maintenance of the metadata files and web pages is enormous. The effort becomes even more onerous if environment changes like the movement and/or replacement of stream server software becomes necessary.
In general, all web servers read http formatted requests from their network interface, process the request according to the rules defined by the http protocol and generate replies that conform to the http protocol definition. More powerful web servers also support active pages like Java Servlets and CGIs (Common Gateway Interface). Java Servlets and CGIs are files containing executable code that are processed by the web server itself. Java Servlets and CGIs are identified by their path and/or their file extension. Parameters passed to the active page have to be attached to the page's URL (e.g., http://www.ibm.com/cgi-bin/service.pl?location=germany).
In “Managing Dynamic Content for a Changing Web”, December 1999, (http://www.newarchitectmag.com/archives/1999/12/bouthillier/), Larry Bouthillier suggests a method for delivering streaming media (hereinafter referred to as the Bouthillier reference). According to his proposal, a video player URL (Uniform Resource Locator) called “play.jsp” is provided and offers users the ability to play any video file or segment and specify start and end times, if desired. According to one embodiment, a hypothetical news organization's Webmaster could provide users with a link to a specific portion of the nightly newscast using a URL (e.g., http://www.ourtvnews.com/play.jsp?segment=dec01—1999_sports3).
This URL accepts the segment, and start or end parameters provided in the URL QUERY_STRING and retrieves the data object for that segment. If start and end times are specified in the QUERY_STRING, play.jsp will play the requested portion of the media file, overriding the start and end time information in the database. Next, it selects a server at random from a server list, and finally, assembles a metafile that will direct a media player, such as RealPlayer™, to launch and connect to the server to play this video. The program sets the MIME-Type in the HTTP result (for example “audio/x-pnrealaudio”) to tell the browser which video player to launch. By changing the MIME-Type, it can be determined, for example, whether RealPlayer is launched as a separate application or embedded in the Web page. Finally, the metafile is printed to the output stream, sending it through the Web server to the client, where RealPlayer™ loads it, subsequently analyzes it and plays the selected video by connecting to a streaming server. According to this approach, access is achieved to respective videos and load balancing among the servers. The videos must reside in a database to be accessible via the Web. Simply adding records to the database creates new playable video segments.